record the spawn win, date the grpc table, and say which rows are noisy#596
Merged
Conversation
three gaps between what the benchmarks show and what the docs said. the coroutine stack pool was described in docs/concurrency.md but its numbers were nowhere: performance.md documented green's flat memory under fan-out and never mentioned that spawning got about thirty times faster. that table is now next to the memory one — 20k spawn-and-join at ~1450ms on os threads, ~580ms on green before the pool, ~50ms after, against go's ~27ms, with the page-fault and context-switch counts that explain it. the grpc table is from 2026-07-20 and predates the wake-path work, so it understates green. rather than replace it with a smaller batch that is not comparable, it is now marked as predating that work, with today's re-run of the same shape quoted alongside: +59% at one green worker and +40% at two, against the +53% and +41% the table records. the relationships hold; only the absolutes moved. the fan-out tables now say plainly which rows to trust. the rows that put eight threads on two cores swing hard run to run — across two suite runs a week apart rust moved 135ms to 94 and zig 135 to 204 with no code change on either side, and pith's os-thread row has been seen from ~260ms to ~940. the green and go rows are the stable ones, so the comparison rests there. docs/limitations.md gains a section on what would have to be true for the green backend to become the default: the one-box measurement problem (the gating question, and a judgement call rather than a task), build-time preemption, blocking dns, and scheduler placement — plus the two remaining bounded-leak ownership gaps.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
summary
docs-only. re-ran the benchmark suite on current main and found three places
where the docs and the measurements disagreed.
the spawn win was undocumented. the coroutine stack pool is described in
docs/concurrency.md, but performance.md — the doc that carries numbers —
documented green's flat memory under fan-out and never mentioned that spawning
got roughly thirty times faster. it now has that table:
the grpc table predates the improvement. it is from 2026-07-20, before the
stack pool, the channel condvar fix, and the slab-free wake, so it understates
green. i re-ran the same shape today: 5067 calls/sec os-thread, 8075 at one
green worker (+59%), 7083 at two (+40%) — against the +53% and +41% the table
records. the relationships hold, so the table stays at its original batch size
with a note rather than being replaced by a smaller, non-comparable run.
some rows are noisy and the docs now say so. across two suite runs a week
apart, rust moved 135 -> 94 ms and zig 135 -> 204 with no code change on either
side, and pith's os-thread row has been seen anywhere from ~260 to ~940 ms.
those rows oversubscribe threads on a 2-core box. the green and go rows are
stable and are what the comparison rests on.
verification that nothing regressed
the correctness fixes merged since the last refresh (#592, #593, #595) touch
extraction and process-io paths, so i checked them against the fan-out
benchmark before trusting any number: green measured 174 ms against 171
documented, go 69 against 75 — both stable. structurally the benchmark's only
hot-path extraction is
counts.recv().unwrap_or(0), a method-call receiver,which the new operand classifier treats as owned and leaves unchanged, and it
makes zero process-ctx reads. no regression, confirmed two ways.
remaining gaps
docs/limitations.md gains a section on what would have to be true for the green
backend to become the default: the one-box measurement problem (the gating
question, and a judgement call rather than a task), build-time preemption,
blocking dns, and scheduler placement — plus the two outstanding bounded-leak
ownership gaps. that section is the pickup point for this work.
what was tested
make docsite-checkpasses (golden output unchanged). numbers come from the9-trial
chan_fanout_bench.sh, the 20k spawn probe interleaved with a gocanary over 5 rounds, and
bench/grpc/run.sh, all on a settled host.